As the computer networks are getting more popular and the development of software applications getting more complex, the software applications are more often executed in parallel in a distributed environment. These applications that run on a master host could use distributed resource manager system (DRMS) to have the jobs executed on available compute servers.
However, in order to use a DRMS, the application developers have to redesign their applications for distributed execution. Normally, the redesigned distributed application submits jobs for execution, stages input and output files for the jobs, monitors and controls the remote jobs by making calls to an application programming interface (API) provided by a DRMS vendor. Typically, commercially available DRMSs have very different APIs that support different remote execution paradigms. As a result, this situation effectively precludes development of distributed applications by independent application vendors who cannot afford to support multiple DRMSs that might be installed on their end user sites.
In addition, one of the obstacles that the distributed application developers are facing is that the DRMS interfaces are designed on how to interact with the DRMS, rather than on how to accomplish common tasks that come up during developing distributed applications. Each DRMS API is distinctly different from each vendor. A developer is not only facing with the task of handling the program logic and mapping it to a variety of DRMS APIs, but also providing ways for an end user of the application to interact with the computing environment.
When a distributed application is an application that spawns child processes, there are situations where the application interchanges data with its child processes via a communication channel. When the child application is sent to a remote site for execution, the communication channel is broken. Therefore, a workable solution is needed.